build: add min release age step - #8164
Conversation
tomdavies73
added
the
Work in progress
There was a problem hiding this comment.
🟡 Changes recommended
The threshold unit is incorrect, and dependency code can execute in parallel jobs before validation.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Adds CI enforcement for minimum npm package release age.
Changes:
- Adds concurrent registry checks for locked package versions.
- Exposes the checker through npm.
- Runs the check before the build job installs dependencies.
File summaries
| File | Description |
|---|---|
scripts/check-release-age.mjs |
Implements release-age validation. |
package.json |
Adds the validation command. |
.github/workflows/ci.yml |
Integrates validation into CI. |
Review details
- Files reviewed: 3/3 changed files
- Comments generated: 3
- Review effort level: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| - name: Check release age | ||
| run: npm run check-release-age | ||
| env: | ||
| MIN_RELEASE_AGE: ${{ steps.age.outputs.min-release-age }} |
There was a problem hiding this comment.
I'm not sure there is a real risk here, our checks are ran in an isolated enviroment so its not the end of the world if we do an npm install elsewhere here.
I think all that really matters is that we throw an exit code 1 and the build fails so we can't merge the PR 👍
| }); | ||
|
|
||
| const now = Date.now(); | ||
| const minimumAgeInMilliseconds = minReleaseAge * MILLISECONDS_IN_DAY; |
There was a problem hiding this comment.
min-release-age=3 will be counted as 3 days, not sure where its getting 3 seconds from. What we have here works as expected
| const response = await fetch(getPackageUrl(registry, packageName), { | ||
| headers: { Accept: "application/json" }, | ||
| }); |
4549819 to
86e36aa
Compare
tomdavies73
added
Pending Review
No QA Required
No UX QA Required
and removed
Work in progress
|
|
||
| const now = Date.now(); | ||
| const minimumAgeInMilliseconds = minReleaseAge * MILLISECONDS_IN_DAY; | ||
| const tooNewPackages = lockedPackages |
There was a problem hiding this comment.
| const tooNewPackages = lockedPackages | |
| const immaturePackages = lockedPackages |
non-blocking just might be more intuitive to non-native English speakers etc
There was a problem hiding this comment.
question: is there anything we can do testing wise here? We'd essentially be assuming this works going forward and potentially not realise if it ever broke for a while so some form of test might act as an early guard against it. Feel free to ping me to chat on slack about this if you want
0c357c3 to
a93a799
Compare
a93a799 to
6c86bf5
Compare
|
🎉 This PR is included in version 161.25.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Proposed behaviour
Adds a build step which will alert us if any packages do not meet our minimum release age. This is particularly useful for dependabot raised PRs as there is currently no way to get dependabot to respect our minumum release age.
This prevents us from accidentially adding recently published packages which are comporomised via dependabot.
Here's a link to a run that shows the new check succesully failing on a recently published package
Here's a link to a run that shows the new check sucessfully failing after the above package met maturity guidelines
Also added a unit test for regression security
Current behaviour
Currently dependabot does not adhere to our minimum release age during security alerts, therefore if we do not verify the package maturity we could accept package updates which are not aligned with our maturity guidelines.
Checklist
d.tsfile added or updated if requiredQA
Additional context
Testing instructions